Many operating systems provide a mechanism for “stitching” or “pipelining” multiple applications (e.g., utilities) together to create a custom, ad hoc command that can be entered on a command line of the operating system. These mechanisms are often used in system administration tools, such as for managing system resources or creating reports on system status. In conventional systems, each “pipelined” utility in the command line communicates with the next utility by passing the results of its operation as text. Thus, each utility in the pipeline is responsible for parsing the received text and for formatting output text. As one can imagine, if a sophisticated command is desired, a system administrator must understand several utilities well to properly pipeline them in a manner that will produce a meaningful output. Understanding the detailed inner-workings of each utility and correctly pipelining the several utilities is time-consuming and is challenging for system administrators.
If an error occurs during one or more of the operations in the pipeline, the system ends up in an indeterminate state because there is no record of the error set. For example, a pipeline of commands may operate on a bulk set of information, such as the names and details of all the files on a storage medium or volume. A first utility in a pipeline may be used to iteratively operate on each item in the bulk set of information and pass the results to a second utility. Errors often occur while the first utility is performing. For instance, the first utility may be performing a rename operation on multiple files but there may be a failure to rename several of the files, such as may occur if the user does not have sufficient privileges or if some of the files are locked in use.
Today, there are no good ways to handle the error. One way to handle the error is to simply stop processing the information on the first error. This option may leave the administrator with the task of discovering which items of information were not processed because of the error. Alternatively, the first utility may ignore the errors and simply continue processing only those items that do not cause an error. Again, the administrator does not know which of the items have not been processed. In some cases, the operation may simply be attempted again, but only in cases where repeating the operation does not achieve a different result than performing the operation the first time. For other operations, simply repeating the same operation on the entire bulk set of information would result in an unintended result.
An acceptable command-line solution that overcomes these problems has eluded those skilled in the art for some time.